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ABSTRACT 



Evolving requirements including the development of the 
Joint Operation Planning and Execution System (JOPES) are 
forcing the WWMCCS ADP community toward the development of a 
distributed data base approach to information management. In 
this thesis the Electronic Data Interchange (EDI) concept is 
examined as a proposed system for realizing a distributed 
data approach. Using the EDI concept, any command which could 
translate to and from the EDI standard data set could exchange 
data with any other participating command. Implementation of 
this sort of system would facilitate interfaces among commands 
while not limiting participating commands to specific hardware, 
software, or data base management systems. The thesis proposes 
the EDI concept as a step toward realization of better data 
distribution and management in WWMCCS ADP. 



4 



TABLE CF CONTENTS 



I. INTRCDUCT ION 7 

II. EACKGROUND 9 

A. WWMCCS ADP OBJECTIVES 9 

B. WWMCCS ADI MANAGEMENT 11 

C. WWMCCS ADP STANDARD APPLICATIONS SOFTWARE . . 12 

III. PROBLEMS 14 

A. THE CPE E NVIRONM ENT 14 

1. Planning 14 

2. Execution 19 

E. SPECIFIC PROBLEMS 21 

C. REQUIREMENTS 25 

IV. RECOMMENDATIONS 27 

A. CHANGING ENVIRONMENT 27 

1. Open System Interface Reference 

Standard 27 

2. Local Area Networks (LAN) 30 

3. WWMCCS Information System (WIS) 30 

4. Summary 31 

B. STANDARDIZATION - A NEW APPROACH 33 

1. Electronic Data Interchange (EDI) .... 35 

2. Application to Specific Problems 42 

C. IMPLEMENTATION 46 

1. Logical Data Base Design 48 

2. Physical Data Base Design 51 

3. Summary 56 

V. SUMMARY- 57 

LIST OF REFERENCES 63 

INITIAL DISTRIBUTION LIST 65 



5 



LIST OF FIGURES 



3.1 Deliberate Planning 15 

3.2 Crisis Action System 18 

4.1 Network 3ased on ISO CSI Reference model .... 29 

4.2 User Capabilities Supported by WIS 32 

4.3 Interfacing under WWMCCS Today 33 

4.4 Interfacing through a Standard Data Set .... 34 

4.5 The Structure of a Transaction Set 37 

4.6 A Communications Session 39 

4.7 Use of Tables in EDI 40 

4.8 EDI Tables - Sample Entries 41 

4.9 Design Considerations for Databases as 

Models 47 

4.10 Data Dictionary 50 

4.11 List of Data Segments 52 

4.12 Data Elements in Each Data Segment 53 

4.13 List of Transaction Sets 54 

4.14 Data Segments in Each Transaction Set 55 

5. 1 WWMCCS Interfaces Today 58 

5.2 Data Exchange Using EDI 58 

5.3 Transmission as Submitted 61 

5.4 Transmission in EDI Format 62 



6 



I. INTRODUCTION 



In the Worldwide Military Command and Control System 
(KHNCCS) current AD? capabilities do not provide sufficient 
support for the exchange of data among commands in a timely 
and effective manner. In order to exchange data today, 
generally, commands must have the same hardware and soft- 
ware. In some other cases specific software must also be 
developed to exchange and translate data between applica- 
tions which are interfaced. These conditions cause 
inefficient use of resources and severely limit capabilities 
to respond to command and control r eguirements. 

Evolving requirements including the development of the 
Joint Operation Planning and Execution System (JOPES) are 
forcing the HUM CCS AD? community toward the development of a 
distributed data base approach to information management. 
In this thesis the Electronic Data Interchange (EDI) concept 
is examined as a proposed system for realizing a distributed 
data approach. 



•'The U. S. Electicnic Data Interchange (EDI) Standards 
are designed to facilitate the electronic interchange of 
data in a standard manner between independently organ- 
ized, owned, and/cr operated computer and communication 
systems. . . The EDI standards grew from needs in 

transportation andpayment applications and have been 
extended for use in other business and technical appli- 
cations." [Ref. 1: p. 6 ] 



Implementation of this sort of system would facilitate 
interfaces among commands while not limiting participating 
commands to s-pecific hardware, software, or data base 
management systems. 
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Chapter II of the thesis provides background by defining 
WWMCCS, and WWMCCS ADP, and explains the current approach to 
HWMCCS ADP management. Chapter III discusses the problems 
of data management in conventional planning and execution. 
In this chapter specific problems are identified along with 
documented requiements which cannot be satisfied using the 
current procedures. Chapter IV, Recommendations, includes 
some background on current capabilities in ADP which could 
be exploited for better command and control. In addition 
the Electronic Data Interchange (EDI) concept is examined as 
a proposed system fcr meeting evolving HWMCCS ADP data 
management requirements. EDI is evaluated in its potential 
to alleviate the specific problems which are identified in 
Chapter III. Chapter V provides a summary of how the EDI 
concept could help improve data interchange among commands 
and includes an illustration of an EDI application. 

The thesis proposes the EDI concept as a step toward 
realization of better data distribution and management in 
WWMCCS ACP. 
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II. BACKGROUND 



A. WNMCCS ADP OBJECTIVES 



''The WWMCCS is the 
Control System that prov 
direction and technical ad 
the function of command an 
tary forces," [Ref. 2]. Th 
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timely and accurate information on the status and 
location of forces and major resources 



the capability to develop and implement both conven- 
tional and nuclear operations plans and options 
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the capability tc formulate and transmit direction 
to and receive and assess reports from the appro- 
priate commands and org ani za tions 



the capability to rapidly and securely exchange 
information, both laterally and vertically, across 
service and command boundaries... 



In general, meeting these objectives will result in a 
capability to capture, transmit, and process information 
in a timely and accurate fashion and to display useful 
and easily understood formats." [Ref. 3: p. a-2j 

T he WWMCCS ADP Concept of Oper atio ns and Ge nera l 
Requirements for Post -1 985 was approved by the JCS and the 
Services in 1981. The documentation identified four func- 
tional families of processing requirements within WWMCCS 
ADP. Most WWMCCS applications software and data bases can 
be grouped into one cf these functional families: 

- Resource and Unit Monitoring (RUM) 

- Conventional Planning and Execution (CPE) 

- Nuclear Planning and Execution (NPE) 

- Tactical Warning/Attack Assessment and Space Defense 
(TW/AA and SD) 

Conventional Planning and Execution will be used to 
illustrate some of the problems which can result when there 
is insufficient provision for interfaces among data bases. 
Conventional Planning and Execution (CPE) generally includes 
the development, maintenance, and execution of operation 
plans for the deployment and employment of United States 
military forces. CPE includes: 

- Generating and refining operatonal requirements 

- Merging requirements from different plans 

- Determining oplan feasibility 

- Matching requirements with actual resources 

- Developing and disseminating schedules and orders 

- Identifying shortfalls and limitations 

- Rapidly reflowing movement requirements 
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- Coordination and monitoring mobilization and deploy- 
ments 

- Aggregating and summarizing requirements 



The CFE fun 
cially since the 
Planning System 
force deploymen 
Operations. "T 
for the developm 
approval cf join 
tions," [Ref. 4: 
Joint Deployment 
and specified co 
and JEA, use the 
ation plan exec 
coordinate amon 
Intercomputer N 
service unique 
data for input t 
unique applicati 
manual as is the 



ction relies heavily on ADP support espe- 
JCS has directed that the Joint Operational 
(JOPS) be used in planning for operations, 
t, and support of U.S. Joint Military 
he JOES consolidates policies and procedures 
ent, coordination, dissemination, revie* and 
t plans for the conduct of military opera- 
p. 3]. In addition - , the members of the 
Community (JDC) , which includes the unified 
mmands, component commands. Services, TCAs 
Joint Deployment System in support of oper- 
ution and monitoring. To communicate and 
g commands in support of CPE the WWMCCS 
etwork (WIN ) is used. Many command and 
software applications are used tc prepare 
o JOPS and JDS, but interfaces among these 
ons and JOPS and JDS are for the most part 
interface between JOPS and JDS. 



B. WHMCCS ADP MANAGEMENT 
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ware . 
system 
support 
ment of 
users. 



management approach which has prevailed in WWMCCS 
teen one of standardizing software as well as hard- 
Kanagement procedures for the WWMCCS standard ADP 
are promulgated in JCS PUB 19. The procedures 
the acquisition, maintenance, and continued improve- 
the WWMCCS standard ADP system and apply to its 
Objectives of these procedures include: 



"reduce the duplication of effort in design, develop- 
ment, acquisition, and maintenance of WWMCCS ADP 
hardware, application software, and system software. 



maximize the benefits of compatibility and 
standardization of WWMCCS AD? hardware, application 
software, and system software," [Ref. 5: p. 11-14] 



C. WWMCCS ADP STANDARD APPLICATIONS SOFTBARE 



" Acplication software 
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a specific technical support 
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fort." [Ref. 5, p. III-2] 
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individual command, Servic 
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standardization of a spec 
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to avoid unnecessary duplic 
spectrum of user reguiremen 

By the late 1980s, t 
its processors and assoc 
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both new hardware and 
system software)." [Ref. 
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originally to operate in 
which makes it- inefficient 
support which generally req 
present a data base must be 
the executing application. 



WWMCCS AD? community is that an 
e, or agency is assigned as the 
ivity (DRA) for development and 
ific application which has been 
The OJCS C3 Systems Directorate 
11 standard systems in an effort 
ation and attempt to meet a broad 
ts. 

his "standard" WWMCCS ADP with 
iated software will be techno- 
ationally archaic and difficult 
(Modernization will require 
new applications software and 
6: p. ES-1 ] 

pplications software was written 
a batch processing environment 
and often ineffective for crisis 
uires interactive capability. At 
resident on the same computer as 
This means that every site using 
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an application must have access to copies or the relevant 
software and data base on the system on which the processing 
will te done. Hany commands have modified their copies of 
the standard applications to better suit their unigue 
requirements so that it is actually no longer the standard 
application software. 
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III. PROBLEMS 
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A. THE CPE ENVI RONMFNT 



1 . P lanni ng 



The JCS has directed that the Joint Operation 
Planning System (JOPS) will le used in planning for opera- 
tions, force deployment, and support of US joint military 
operations. JOPS supports planning under time-sensitive or 
crisis conditions with procedures which form the Crisis 
Actior System (CAS) . Under non-crisis, peacetime situations 
JOPS is employed in the deliberate planning process. 

a. Deliberate Planning 

Deliberate planning consists of five phases 
which are outlined in Figure 3.1 [Ref. 4: p. 3] 

The major product created during the plan development phase 
of JOPS is the time-phased force deployment data (TPFDD) . 
When planning is complete, the TPFDD contains all of the 
information needed to describe a deployment. TPFDD refine- 
ment is conducted in a two-phase conference hosted by the 
Joint Deployment Agency (JD A) . 

The WIN is utilized as a timely, secure means of 
distributing data to the deployment community to facilitate 
the refinement process. Prior to the Phase I refinement 
conference the WIN is used to distribute the unrefined 
TPFDD, which contains only notional data, to the deployment 
community in order that initial analysis can be conducted 
prior to the conference. During the Phase I conference as 
actual forces are designated to replace the notional forces 
in the TPFDD and transportation requirements are identified, 
the TPFDD is updated to reflect these changes and 
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1 



Phase I 



Initiation 



Basis: National Security Objectives 

Criteria: The Threat 

Planning Tasks and Forces 
Objective: To Set the Stage 



Phase II 



Basis: Mission Assignment (Forecast Situation) 

Concept Criteria: Force and Resource Allocation 

Development All Significant Factors 

Objective: Derive the Concept of Operations 



Phase III 



Plan 

Development 



Basis: 

Criteria: 



Objective: 



The Commander’s Concept 
Force and Resource Allocation 

Service Planning Factors 
Strategic Movement Data 
Concept Adequacy 

A Transportation Feasible, Implementable Plan 



Phase IV 



Plan 

Review 



Basis: The Plan 

Criteria: Adequacy, Feasibility, and Suitability 

The Dynamics of Change 
Objective: An Approved Plan 



Phase V 



Supporting 

Plans 



Basis: 

Criteria: 

Objective: 



The Approved Plan 
Service Doctrine 
Support Agreements 
A Family of Plans 



Figure 3.1 Deliberate Planning. 

distributed to the TCAs. Each of the TOAs uses command 
unique applications software to prepare movement schedules 
supporting the requirements in the TPFDD and to check the 
resulting schedules for feasibility of execution, identif- 
ying shortfalls (requirements which cannot be met) . 
Military Airlift Command (MAC) forwards the TPFDD by WIN to 
Military Traffic Management Command (MTMC) after identifying 
airlift in support cf the plan and checking the plan for 
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feasibility. As the provider for ground transportation and 
transportation within the continental United States, MTMC 
identifies and tests for feasibility the transportation 
support to be provided by MTMC. The RIN is used again to 
forward the TP FDD tc Military Sealift Command (MSC) . The 
sealift support for the plan is identified, as well as the 
resulting shortfalls, and the TPFDD , with air, ground, and 
sea transportation identified, is forwarded by WIN to the 
Joint Deployment Agency. In addition, the modified TP FDD is 
distributed to the deployment community for review of short- 
falls prior to the Phase II conference. During Phase II of 
the refinement process as shortfalls are studied the plan is 
modified tc resolve the shortfalls, resulting in the 
requirement for reflcwing the transportation support. 

When the TPF DD has been refined and the 
resulting CFLAN reviewed and approved by the Joint Chiefs of 
Staff, it is then entered into the deployment data base at 
JDA and is accessible to the deployment community by means 
of the RIN. 



b. Plan Maintenance 

An ongoing teleconference is maintained for each approved 
OPLAN in order to provide a forum for discussing changes 
required tc maintain and update the plans. 



Usually the first 15 days of airlift and the first 30 
days of sealift are reviewed by the appropriate members 
of the Joint Deployment Community, wno verify that the 
units and material designated in the plan are actually 
available, and would most likely be the ones used, 
should the plan be executed... upon completion of the 
maintenance cycle, the revised data replaces the 
outdated requirements in the Joint Deployment System 
(JDS) , [Bef. 7: p. 13]. 



This review is usually conducted quarterly. 
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c 



Time-sensitive Planning 



The Crisis Action System (CAS) which is utilized 
for time-sensitive planning has six phases as illustrated in 
Figure 3.2 [Ref. 4: p. 7]. 

In the situation development phase commanders 
can use the KIN to submit Operational Reports (OPREPS) to 
appropriate authorities. CPREP messages are used to commu- 
nicate concerning incidents or conditions which could evolve 
into a crisis. 

In the crisis assesment phase WIN is used to 
conduct a teleconference in which representatives from the 
NMCC , the Service headguarters, the Unified and Specified 
Commands, the JDA, and the TOAs participate. 
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Figure 3.2 Crisis Action System. 



In the course of action development phase the 
WIN is utilized as the transmission mode for the CPHEP-1 
messages used to exchange reguired information. Using CREEP 
messages on the WIN, JCS promulgates a warning order, the 
supported commander then tasks the deployment community for 
reguired assistance in developing or revising plans. The 
depolyment community in turn forwards responses and the JDA 
updates the JDS data base for the plan being developed or 
modified. 

In the execution planning phase WIN is used for 
transmission of the alert order and operation order. The 
deployment community develops supporting operation orders as 
reguired and uses WIN to forward updated information to JDA 
for inclusion in the JDS data base. 

2. Execution 

"The Joint Deployment System supports deployment execu- 
tion and sustainment of forces. . .After the JCS execute 
order, the JDS must monitor status of deploying forces, 
material, and non-unit related personnel. .. JDA must also 
be able to rapidly respond to changes in the deployment 
as execution processes." [Ref. 7: p. 16] 

The JDS capabilities supported by WIN, which are 
available to the joint deployment community during deploy- 
ment execution are: 



- A teleconference is used 
tion among the members of 
assist in decision making. 



to exchange textual informa- 
the deployment community to 



- Access to the JDS data base is available by one of the 
following means: 
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Direct access to the JDS data base is 
possible using WIN to access the timesharing 
subsystem of the JDA host computer. By this 
means remote users can review or update the 
JDS data base. 

— Transfer of portions of the JDS data base 
to remote sites is possible using WIN. Then 
users at remote sites can run command unique 
applications programs using their copies of 
the JDS data base. These copies of the data 
base will not reflect updates to the data base 
at JDA unless a later transfer is initiated. 

Direct access to the JDA data base is 
possible throught the JDS Remote Users Package 
(RUP) which permits the user to update a local 
copy cf the JDS data base while simultaneously 
updating the JDS data base resident on the JDA 
This permits commands to have 
te most up-to-date version of the 
> cn a real time basis. 

The RUP is considered to be the prefered method for 
formation between JDA and the remote 
Ly provides the remote user the capa- 
Lssion of updates and changes hut also 
=r to recieve changes simultaneoulsly 
is updated by other members of the 
In addition the RUP permits the 
oommand unique applications programs 
f the data base. "As part of the RUP, 
communication support software called 
Processor which uses existing WIN to 
pdates between two WIN sites in near 
real time." [Ref. 7: p. 70]. 
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The JDS also interfaces with MAC and MTMC using »IN 
to transfer information to and from 

the Integrated Military Airlift Planning System 
(IMAFS) at Military Airlift Command 

- the Motility Analysis and Planning System (MAPS II) at 
Military Traffic Management Command. 

These automated interfaces facilitate the timely exchange of 
movement reguirements and scheduling information between JD A 
and the TOAs. 



E. SPECIFIC PEOELEMS 

Several examples of the kinds of problems which occur in 
processing in a distributed environment can be found in 
examining the JDS as part of the KWMCCS ADP support for CPE. 

a. Interface Between JOBS and JDS 

The JDS is the AD? tool used to manage informa- 
tion in support of deployment and OPLAN execution. In order 
to properly support its mission the JDS must interface with 
JOPS which is used to develop oplans. The current interface 
is, "time-consuming and relies heavily on manual reviews and 
manipulation of ’data 1 ," [Hef. 8: p. 8]. The JOPS handles 
notional data, dealing with types of units rather than 
specific named units. JDS, however, has in its data bases 
specific named units which will be used in specific plans. 
In order to obtain the proper information for the JDS data 
base, manual reviews cf the notional JOPS data are conducted 
and after specific actual units are named in support of 
reguirements, the JDS data base is prepared. In addition, 
each cf the TO-As requires support from command unique soft- 
ware to convert the notional movement tables from JCPS into 
schedules which use actual named assets. These schedules 
are then used to provide input for the JDS data base. 
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The interfaces among these systems are primarily 
manual at tne present time. In addition, although the WIN 
is used to transfer data between participating commands, 
each command running JOPs uses its own copy of the T? FDD 
during processing as well as its own copy of the JOFS soft- 
ware. Ihis results in considerable duplication of files and 
a resulting requirement for extensive coordination tc ensure 
each site is using copies of the same TPFDD data base in 
order to prevent decrepancies. 

b. NOPLAN Support 

"There are no adequate procedures to rapidly 
establish a deployment data base in a NOPLAN situation," 
[Ref. 8: p. 11]. Since in the current JDS the only way to 
review data is in connection with one specific OPLAN at a 
time, it is difficult to efficiently use data already in the 
data base in support of a NOPIAN situation. There is not 
even automated assistance to determine which units are 
tasked tc support more than one OPLAN. This is a deficiency 
in the current system since there is a validated requirement 
that, "The JCS will review the supported commander's esti- 
mate and approve or modify the recommended course of action 
after determining the effect on other operation plans and 
global capabilities," [Ref. 9: p. 12]. There is currently 

no timely, efficient way for commanders to share NOPIAN 
information when developing potential courses of action 
without actually sending copies of data bases or lengthy 
messages between commands. 

c. Data Base Incon sistencies 

The primary method for transfer of data among 
commands using the JES is the WIN. Recent tests conducted 
during a major exercise have shown in a fairly small sample 
of JDS data base records that there are numerous 
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the data base at various 



inconsistencies among copies of 
sites (Joint Deployment Agency, European Command, Military 
Airlift Command) : 



"The technique we used to determine the synchronization 
of JDS data bases was to select a sample of carrier 
records and determine if the information was the same in 
each of the three data bases. . .This oplan has thou- 
sands of carriers, so we limited our sample to these 
carriers we knew had been updated--those with Deviation 
and /or Diversion reports. We retrieved carrier mani- 
fest data on forty-rive records stored at each of the 
three locations ... In summary, this very small sample 
of carrier records having been modified by deviation/ 
diversion reports, had a high percentage of differences 
between ROP and JDS data bases." [Ref. 10] 



The data shown furnishes examples of the 



found : [Ref. 10 ] 

CARRIER A 038 9 5 
EUCCM 
JD A 



SCH ARR 

255426 ZFEE AT 3RUSSELS 
250000 0FEE AT BRUSSELS 



discrepancies 



Discrepancy: 



a difference in scheduled arrival time 



CARRIER A04526 

EUCCM 

JDA 



SCH DEP 

CITY OF COLORADO SPRINGS (TDHV) 
PETERS CN FIELD (TDHV) 



Discrepancy: a difference in the name associated with a 

specific location cede 



CARRIER A 0 40 2 1 v 

EUCCM 

JDA 



SCH ARR 
251626 ZFEB 
2500000FEE 



Discrepancy: a difference in the scheduled arrival time 



SCH ARR CARRIER DEVIATION 

261651 ZFEE 



CARRIER A04182 
EUCCM 
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JD A 



260000 OFEE 



DELAYED 2 HOURS CUE TO 
DEMONSTRATION AT APCD 



Discrepancy: a difference in the scheduled arrival tine 
and a note concerning carrier deviation which only shows 
at cne site 



The need for complete, accurate, timely informa- 
tion is often taken for granted. In the CPE environment 
this requirement is even more challenging since all partici- 
pating commands need to be working with identically updated 
data bases if they are to make valid assumptions for plan- 
ning and executing oplans. 

d. Data Base Management 

'•There is also a requirement to develop a system to restrict 
access to data and restrict the capability to change data 
elements within JDS," [Bef. 11: p. 2-10]. Safeguards to 

prevent unathorized changes to data elements in the JDS are 
insufficient. An authorized JDS user with modify permis- 
sions may make unauthorized modifications in the data base 
since individual types of changes or types of data elements 
are insufficiently safeguarded. 

A change or update to the JDS data base using 

may not update relevent corre- 
For example, 

reported as sunk using one update mod 
display ships arriving on a given date 
ship as scheduled to arrive. 

"A major problem facing ti 
is the lack of standardization of dat 
JOPS, JDS, UNITREP, and OPREP. Becaus 
modate the interface with these system 
to pick and choose between vai 



one update module may or 
sponding data elements. 





ir a 


came 


r 


IS 


e 


a quer 


y modu 


le 


to 


ay 


still 


displa 


Y 


the 


de 


ployment ccmm 


un 


ity 


elements 


b e t w e e 


n 


the 


of 


the ne 


ed tc 


ac 


co- 


JDA has 


been f 


or 


ced 


US 


data 


elem 


en 


ts. 



24 



definitions and formats," [Ref. 11; p. 3-8]. The following 
are seme of the problems resulting from the attempt to 
interface these systems: 

- data elements which actually have the same meaning 
have different names (e.g. different versions of an 
airfield name associated with the same location code) 

- data elements which have the same meaning may have 
different units or be calculated using different algor- 
ithms (e.g. weight reflected in long tons on one system 
and short tons on another) 

- data elements which have different meanings have the 
same names (e.g. arrival date on one system may he the 
time a unit will arrive in theatre, on another system it 
may be the time a unit will arrive at port of debarka- 
tion) 

As the data base structure or the basic software 
of the JES changes, the command unique queries written to 
run against the JDS data base must also be changed. 

C. REQUIREMENTS 

In July 1983 the Joint Chiefs of Staff approved the 
Joint Operation Planning and Execution System (JCPES) 
Required Operational Capability. The initial operational 
concept, 

"Addressed procedures supported by state-of-the-art ADP 
capabilities which would result in producing 
capability-const rained courses of action in a matter of 
hours and completed plans, fully sourced with actual 
units tested against deployment ana sustainment capabil- 
ities, within days. These criteria, once achieved, 
represent a- revolutionary improvement to present plan- 
ning system capabilities." [sef. 9], 
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our CCEV62- 



JCPES is envisioned as, "The foundation for 
tional command and control system," and will ac 
functions, "through the interoperation of a cen 
joint applications and various C2 and functional 
. JOPES must support the planning and executio 
theater scenarios involving total commitment of 
Allied forces," [Ref. 12], 

JOPES will effectively replace the JOPS an 
today support CPE. JOPS and JDS are two sepa 
which do not have an automated interface. JOPS 
planning and JDS for execution. .In JOPES 
supporting these functions would not require 
interfaces required today. In addition, JO 
required to share data with command unique 
which support CPE. 



"JOPES consists of the p 
hardware, personnel train 
to facilitate planning 
toring and controlling m 

p. 2] d 
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Eor JOPES tc work effectively the WWMCCS communi 
to develop and support a distributed data base c 
will pernit interfacing command unique software 
standard software. In a distributed data base, 
the data are stored cn different computers, 
location of the data ideally does not affect pr 
is usually not even apparent to the user. This 
nate the need for synchronizing multiple cop 
bases (except these required for redundancy). S 
ronment would also eliminate the manual manipula 
currently required in interfacing the existing s 
support CPE. 
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IV. RECOMM ENDATIONS 



A. CHANGING ENVIRONMENT 

The current state of the art in automatic data 
processing offers many management and technical opportuni- 
ties to facilitate the transition from the WviMCCS Standard 
ADP of today to the kind of system required to support the 
evolving needs of the CPE environment. The requirement to 
share data among commands in support of CPE requires addi- 
tional techniques and facilities not required by a single 
site operating in isolation. The Open System Interface 
reference model proposed by the International Standards 
Organization provides a means to describe and document the 
interfaces required in a computer networking environment. 
Ihe capabilities provided by local area networking offer the 
facility to link internal command resources together in 
support of command unique requirements. The WWMCCS 

Information System is the onging program to modernize WWMCCS 
ADP utilizing modern technology to meet evolving require- 
ments. 

1 • O pe n S y s te m Int erf a ce Ref e re nce St a ndard 

The International Standards Organization (ISO) 

proposed the Open System Interface (OSI) Reference Model to 
serve as a standard set of network interfaces and protocols. 
The use of the OSI Reference Model would be a step toward 
international standardization of the various protocols for 
distributed processing networks. Compatibility among 

network nodes would be assured by compliance with standards 
even when software and hardware at various sites are 
supplied by different vendors. 
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The OS I standard is based on a seven layer concept. 
Each layer provides a portion of the services required to 
interface nodes in the network. By breaking the interface 
problem into seven layers, the implementation of different 
portions of the interface can be developed, tested, fielded, 
and modified independently. The layered approach helps to 
isolate the functional requirement from the engineering 
implementation. As mere efficient technology becomes avail- 
able the implementation of a specific portion of the 
interface can be changed without undue influence on the 
users' interaction with the overall information network. 

The bottom three layers of the OSI model are host to 
imp protocols and the top four layers are host to host 
protocols. Only the top two layers deal with interfacing 
user applications and data. 

LAYEE 1: The Physical Layer supports the actual ccramuni- 
caticn connection between hosts and the transmission of 
raw data ever the established channel. 

LAYEE 2: The Data Link Layer ensures data received is 

error free and the appropriate acknowledgements are 
sent. 

LAYEE 3: The Network Layer, sometimes called the commu- 

nication subnet layer, is responsible for point to point 
routing of data between its origin and destination. 

LAYEE 4: The Transport layer, also called the Host-Host 

layer, is concerned with dividing the data into packers 
for transmission. 

LAYEE 5: The Session Layer provides the capability for 

users cf different machines to establish a connection 
between processes on the machines. 



28 



LAYER 6: The Presentation Layer manages the exchange of 
data between applications anywhere on the network. It 
ensures the data is in appropriate format for the appli- 
cation to which it is being sent. 

LAYER 7: The Application Layer provides the interfaces 
between user and application and the user and the 
system. 



Layer 



Name of unit 
exchanged 




Message 



Message 



Message 



Message 



Packet 



Frame 



Bit 



* — Physical layer host - IMP protocol 



Figure 4.1 Network Based on ISO OSI Reference Model. 
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Figure 4.1 [Be£. 13: p. 16], illustrates a network 

based on tie ISO OSI Reference Model. The dotted lines 
represent virtual connectivity between similar layers on 
different hosts while the solid lines represent physical 
connectivity. The ISO OSI provides a useful way of 
describing protocols which perform required network func- 
tions while leaving the engineering of the implementation up 
to the network designers. 

2. local Area Networks (L AN ) 

local area networks (LAN) are networks which provide 
high speed communications among information processing 
equipment in a limited geographic area. Local area networks 
have evolved from previously existing methods of networking 
and communicating. They provide the capability to interface 
many kinds of devices and to exchange data with other LANs 
or long haul networks. In general, LANs offer high data 
transmission speed at lowered costs while sacrificing long 
distance data transmission capability. LANs are a key 
element in the strategy for the HWMCCS Information System. 
Attributes of LANs which are being evaluated for support of 
WIS include: 

flexible topology 

security 

expandability 

flexibility in selecting transmission media 
reliability. 

3 . HW M CCS Inf o rmation System ( HI S) 

’’The HWMCCS ' Information System (HIS) encompasses the 
infcrmaticn collection, processing, and display system 
that includes HWMCCS ADP and related software systems, 
procedures, and supporting telecommunications. The 
modernization focus is on the backbone of standard 
HWMCCS ADP which supports command systems . . . The JPM 
(Joint Program Manager) focus will be on software and 
data management techniques." [Ref. 14: p. ES-1] 
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"The KIS JPM task is to modernize and enhance the 
command control software, acquire state-of-the-art hard- 
ware and add capabilities to the command control 

E rocess. These capabilities include automating the 

andling of operational messages, distributing data and 
enhancing the capability of command control personnel to 
interact with their information." [Ref. 15: p. 17] 
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iflsaujsra 

WORK STATIONS 




• OUTGOING MESSAGES' 

• QUERY/ RESPONSE 

• TELECONFERENCE 

• DISPLAYS 

• OATA 3ASE SUMMARIES 



JRS MESSAGES 
• OTHER MESSAGES 
• QUERY/RESPONSE 
• TELECONFERENCE 
• DISPLAYS 
8 OATA BASE UPDATES 
FILE TRANSFERS 



EXTERNAL INTERFACES 




LOCAL USER WORK STATIONS 

• COW1ANO CENTER PERSONNEL 

• CRISIS ACTION TEAMS 

• OPERATIONS SUPPORT PERSONNEL 



Figure 4.2 User Capabilities Supported by WIS. 
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E. 



STANEABEIZATION 



A NEW APPROACH 



The growing requirement for automated interfaces between 
the programs and data bases used by different commands to 
support CEE cannot be supported using the current WWMCCS 
Standard Software. If commands want to interface software 
today, the interfaces must be designed individually and 
uniquely tailored to the two ends of the interface. Figure 
4.3 illustrates the interfaces which would be required to 
link the software of four members of the joint deployment 
community today. Each line represents a specific interface 
developed between applications at two commands. In this 
example six programs are required to interface each of the 
four ccmmands to each of the other three. 




Figure 4.3 Interfacing under WWMCCS Today. 

It is clear that in addition to necessitating many man- 
years of software development, an interface would require 
updating each tine an application on one end was modified. 
The requirement still exists, however, to share data among 
commands. In JOPES, 



"Once an originating agency updates its data base, the 
distributed data base concept will permit automatic 
updating, in summary format, of all interrelated data 
bases . . . JOPES will not burden lower level staffs 

with extensive reporting requirements but will interface 
with command and aqency-uniaue systems as necessary and 
within owner specified limits to rapidly obtain informa- 
tion." [ Eef . 9] 
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JDA has made progress with near real-time updating of data 
bases located at different commands but the JDS requires all 
participating commands to be using exactly the same JDS 
software, operating on the same WWMCCS Standard Hardware. 
This approach does net permit the interfacing of command 
unigue applications and data bases among commands. 

In order to obtain the benefits of timeliness and accu- 
racy in interfaces, an AD P solution is preferable to the 
current manual interfaces. If the WWMCCS community would 
define a core set of data which is required for CPE and 
standardize the description cf this data, each command 
seeking to interface with another command would only have to 
develop an interface between the standard data set and their 
command unigue software. Figure 4.4 illustrates the Joint 
Deployment Community interfacing in this manner. 



JDA 

MAC 



INT EBFACE 




M SC 
MTMC 



Figure 4.4 Interfacing through a Standard Data Set. 

The total number of interfaces would be reduced signifi- 
cantly and each command would only have to plan one 
interface with the standard data set in order to interface 
an application with all other participating commands. In 
this example the total number cf interfaces was reduced from 
six to four by interfacing through a standard data set. 
More important, each node new only requires one interface 
vice the three previously required. The use of a common 
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interface permits many widely separated data bases to func- 
tion virtually as a distributed data base. This will help 
meet the identified requirement for a distributed data base 
approach tc support JOPES. It is not a distributed data 
base in the routine sense but rather an interface which 
permits the exchange of data among separate data bases. 
This concept is further developed in a later section. 



1. El ectr onic Data Int erchange (EDI) 



a. Background 



"The U.S. Electronic Data Interchange (EDI) 
Standards are designed to facilitate the electronic inter- 
change of data in a standard manner between independently 
organized, owned and/cr operated computer and communications 
systems," [Bef. 17: p. 9], The EDI standards were devel- 

oped in an extensive joint government-industry effort to 
meet a recognized need in the transportation industry for 
timely, reliable transmission of data among organizations. 
The organizations utilizing the EDI standards include: 



Motor Carriers 

Ocean Carriers 

Air Carriers 

Railroads 

Brokers 

Shippers 

Consignees 

Freignt Forwarders 

Freight Consolidators 

Banks 

Agents 

U.S. Customs Service 
U.S. Department of Agriculture 
U.S. General Services Administration 
U.S. Department of Defense. 
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fc. 



Structure of EDI 



The major unit of information in EDI is the 
transaction set. Transaction sets support the major func- 
tions performed by the communicating organizations. 
Information units in the EDI include: 



•'Data Element: The smallest information unit in the EDI 

information structure is the data element. A data 
element may be a single character code, a series of 
characters constituting a literal description, or a 
numerical quantity. 

Data Segment: A data segment is composed of a function 

identifier and one or more functionally related data 
elements positioned serially in a standard manner . . .A 
segment is roughly equivalent to a line of information 
on a bill of lading or freight bill. 

Transaction Set: A transaction set is a group of data 

segments, in a predfined sequence, needed to provide all 
of the data required to define a complete transaction 
such a s shipment information or invoice . The trans- 
action set in EDI eguates to a document in a paperwork 
system, such as a hill of lading or invoice. 

Functional Group of Transaction Sets: A functional 

group identifies these transaction sets of the same type 
(having the same indentifier and subject title)." 
[Ref. 18] 



Figure 4.5 [Ref- 19], shows how the information units are 
put together to build a complete transaction set. The first 
data segment shown in the second column of the example is 
composed of the first four data elements in the first 



column. This same data segment becomes the first part of 



the transaction set 


in column 


three . 


It 


should 


be noted 


that a data element 
data segment. 


(e.g. A) 


can be 


used 


in more 


than one 
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Figure 4.5 The Structure of a Transaction Set 



Figure 4.6 [Ref. 19], shows how a communications 
session with a user inputting data into the network can 
include note than one transaction set. This figure fellows 
the building block approach by showing that related trans- 
action sets (e.g. purchase orders) can be regarded as a 
functional group and several related or unrelated functional 
groups can he sent in the same transmission. 

c. EDI Operations 

The EDI concept operates through the use of five 

tables. 



•'The same five tables are used for generation of data to 
be transmitted and for the interpretation of data that 
is received. The set of tables defines the structure 
and attributes of the EDI transaction sets, segments, 
data elements, and codes. The EDI operational software 
programs control pointers to these tables and use the 
information at the pointer locations, in combination 
with data from the user’s data base, to assure program 
generation and interpretation of data." [Ref. 19] 
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Comnum cations Protocol 



Transmission Control Header Segment (8G) 
Functional Control Heaoer Segment (65) • 



Transaction Set Control Header Segment (ST )- 
(Beginning Segment) 



(Detail Data Segments 
(e.g. Purcnase Droer) 



Transaction Set Control Trailer Segment (St) 
(Ending Segment) 

Transaction Set Control Header Segment (ST ) 
(Beginning Segment) 



Detail Data Segments 
(e.g. Purcnase Order) 



Functional Control Trailer Segment (G£)« 
Functional Control Heaoer Segment (G S) ■ 



Detail Data Segments 
(e.g. Receiving Mv ice) 



Functional Control Trailer Segment (Gc) 
Transmission Control Trailer Segment (EG) 



Transaction Set Control Trailer Segment (SE)« 
(Ending Segment) 



Transaction Set Control Header Segment (ST ) • 
(Beginning Segment) 



Transaction Set Control Trailer Segment (SE)- 
(Enomg Segment) 



Comnum cations °rotocol 



'he 'rsnsmtsston Control ^e«er ana T ransrmssion 
'railer are not jsefl in Ail contnumcitions . 



Figure 4.6 a Coaaunications Session. 
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Table 1 is used to locate items in Table 



Table 2 gives the order of segments in a 
transaction set for each application. 



Table 3 is used to locate items in Table 
4. 



Table 4 gives the order of data elements 
in each segment. 

Table 4 example (simplified) : 

Segment I.D. Data Element Location 



EX (Example) 


D 


11 


EX 


A 


1 


EX 


E 


13 


EX 


C 


9 



Table 5 specifies data element attributes. 
Table 5 example (simplified) : 



Data Element Maximum Length 



A 

B 

C 

D 

E 

F 



4 

4 

2 

2 

12 

8 



L 



Figure 4.7 Use of Tables in EDI. 



40 



“1 




41 



Figure 4.8 EDI Tables - Sample Entrie 



d. Advantages of EDI 

The emphasis in the EDI concept is on communica- 
tions (exchange of information) between computers. 3y 
communicating through the use of standard transaction sets, 
EDI permits users to interface efficiently while preserving 
their autonomy. Each user could conceivably be using 
different kinds of hardware, software, and data base manage- 
ment systems and still be able to communicate. An added 
benefit cf the EDI approach is that data elements can be 
added or deleted without reguiring software logic changes. 
Also, changes in a user’s applications will not affect the 
interface with other users as long as the translation tc the 
EDI standard is updated within the command. 

The EDI concept could be used within the WWMCCS 
community tc ease the transition to the distributed data 
base environment which will be required to support CEE. To 
implement this approach, members of the WSMCCS community 
would have to define the applications and the data which are 
required to support CEE. Standard methods for data control 
would be required. Once the standards were developed and 
documented it would be the responsibility of each command to 
make the translation between their applications and the 
standard. Cnee all the involved commands are able tc trans- 
late between their applications and the standard, they could 
also communicate directly with ether participating commands. 

2 . App lica tion tc Specifi c Pr ob lems 

The desirability of implementing the EDI concept 
within the WWMCCS community can be evaluated by examining 
how it would help resolve the some of the problems which 
have been identified in WWMCCS ADP support of CPE. 
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a. Data Base Management 
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By distributing the data and controlling communications 
access to specific data, the EDI concept provides more secu- 
tity than the current system. 

In the current system a change or update to the 
JDS data base using one update application may or may not 
update relevent corresponding data elements. Using the EDI 
approach, many applications could rely on a single copy of a 
data element so the opportunity for discrepancies would be 
minimized. Today different applications use different files 
and it is difficult to effectively update all instances of a 
data element. In addition, through use of the transaction 
sets, groups- of related data elements could be updated 
together. 
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- data elements which have the same meaning may have 
different units or be calculated using different algor- 
ithms 



- data elements which have different meanings have the 
same names 
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"To respond with ease to frequent requirements for modi- 
fication, contraction, and/or expansion of the 
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individual applications. . . the information is 

structured so* that it may be constructed by one computer 
system and interpreted and processed by another. New 
applications and information units may be specified 
without impacting work previously completed." [Bef. 17: 
pp. 6-13] 



The physical implementation (e.g. the programming languages 
and the data base management system) of any standard or 
unique application is kept isolated from the standard data 
definitions so modifications to implementation methodology 
will not destabilize the system. 

fc. Data Base Incon sis tencies 

The problem of different sites having different 
copies of the data tase would be avoided through the EDI 
concept because of the distribution of data. Each data 

element would reside at the command responsible for its 
accuracy but would be accessible to other commands. Even 
with provision for redundancy this is still a more desirable 
arrangement than multiple copies of data bases residing on 
many systems at many locations. In this way, as data is 

updated for one purpose (e.g. UNITREP) the updated data 

would also be available for other applications such as JCPS 
or JDS without requiring separate updates for each applica- 
tion. 

c. NOPLAN Support 

The use of the EDI concept could help in a 

NOPLAN situation by eliminating the necessity to send copies 
of entire data bases or lengthy messages among commands. As 
each command successively develops a portion of the plan, 
data can be ex-tracted from applicable data bases, incorpo- 
rated into transaction sets and transmitted to ether 
involved commands. Because the construction of new 

instances of a transaction set can be facilitated by the EDI 
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tions. It would also be p 
information on a specific 
the unit was tasked. Thi 
data segment which includes 
nation and the plans which 
problems with multi-tasking 
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d. The Interface Between JCPS and JDS 



The interface between JOPS and JDS, and other standard or 
command unique applications could be significantly simpli- 
fied through the EDI CONCEPT. Since incompatibility of data 
elements is not a problem when the common interface is used, 
data from numerous systems could be tapped in response to 
information queries input using any one of the systems. 



C. I BP LE MENTATION 

Although the EDI concep 
elements in order to cperat 
dard data base. EDI facil 
various data bases by means 
the groundwork for an E 
however, similar to data ba 
examine the necessary prep 
data tase design terms. 

A data base is a model 
in the real world. Events 
reported to t-he data base 
turn cause data to be modi 
data bases as models are li 
177], 



t requires a standard set of data 
e, there is no centralized stan- 
itates the transfer of data among 
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DI interface is in some ways, 
se design. It will be helpful to 
aration for implementing EDI in 
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which occur in the real world are 
system as transactions which in 
fied. Design considerations for 
sted in figure 4.9 [Ref. 20: p. 
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Database as a model of an enterprise 
Level of detail 

Cost of aggregation and generalization is unanswerable question 
Need to aggregate and generalize in light of requirements and 
financial resources 

Dynamics of database as model 

Enterprise changes, model must change 

Events occur, are represented by transactions 

Level of transaction important - transactions cannot be more 

aggregated or generalized than database data 

User views 

Different perception of data structure 
Different perception of data meaning 
Need for standardized meaning 




Figure 4.9 Design Considerations for Databases as Hodels. 

The fact that in CPE users represent many commands with 
different views can cause a design problem. 



"Different users (and desianers) will have different 
meanings and interpretations for data that is stored in 
the database. Questions that appear to be similar may 
in fact be different." [ Bef . 20: p. 177] 

Definition of a set of data elements which must be 
available in an EDI interface would require a great deal of 
effort with high level support in the joint arena. The 

standard data elements will be the building blocks from 
which interfaces will be constructed. 



'Data tase design is divided into two phases: logical 

design, where the needs of people are specified, and 
physical design, where the logical design is mapped into 
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the constraints of par 
products, 1 ' [Ref. 2C: p. 
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1 • lo gica l Data Ease D 
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h. Input 
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c. Procedures 
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"The major steps in the logical design process: 

- identify data to te stored 

- consolidate and clarify data names 

- develop the logical schema 

- define processing 

- review design," [Ref. 20: p. 181]. 
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In the process 
stored, the data dictionar 
are identified by name 
[Ref. 183/ is an example 
dictionary. Tc see how 
consider data element "10" 
" 10 " is defined as a six 
entered with the first two 
digits of the year, the m 
month, and the last two di 
month. Ihis physical des 
also accompanied by a verba 
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names for the same data 
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they design to interface 
standard . 

The development 
of defining data segments 
4.11 and figure 4.12 are 
list data segments and the 
built. [Ref. 19]. In T 
segment titled "beginning s 
assigned the segment ID num 
composed of three data el 
These data elements can be 
4.12) by finding the segm 
column. The second co 
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gits representing the day of the 
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1 definition of the data element. 
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system. EDI eliminates the need 
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their unique system to the EDI 
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her "B7". This data segment is 
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ent ID number "57" in the first 
lumn lists each data element 
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data elements 



2 ACCEPTED SETS 

(SPEC: TYPE- N MIN • 1: MAX' 3) 

NUMBER OF TRANSACTIONS RECEIVED WITHOUT ERROR IN A 
FUNCTIONAL GROUP (NUMBER MAY BE 0) 

REFERENCE OESIGNATOR! S ) : 8502 



3 FREE-FORM MESSAGE 

(SPEC: TYPE- AN MIN' 1; MAX • 60) 

FREE-FORM TEXT 

ALSO SEE: NOTE REFERENCE COOE (343) 

REFERENCE DESIGNATOR ( S) : K201 NTE02 



3 ARRIVAL DATE 

(SPEC: TYPE • N MIN • 6: MAX' 6) 

DATE (YYWMDO) AS REQUIRED BY CUSTOMS 
ALSO SEE: ETA OATE (45) 

REFERENCE OES IGNAT 0R< S ) : X302 



7 BANK ACCOUNT NUMBER 

(SPEC: TYPE • n MIN' 6: MAX' 17) 

ID NUMBER ASSIGNED BY 8 ANA TO ITS CLIENT 

REFERENCE DESIGNATOR! S) : C205 



3 BANK CLIENT CODE 

(SPEC: TYPE- A MIN' 1; MAX' 1) 

IDENTIFICATION OF PAYEE OR PAYER: 

COOE OEFINITION 

E PAYEE 
R PAYER 

REFERENCE DESIGNATOR! S ) : C201 



9 BANK PLAN NUMBER 

(SPEC: TYPE' N MIN' f; MAX' 6) 

NUMBER ASSIGNED BY BANK TO PAYER’S FREIGHT PAYMENT 
ACCOUNT 

REFERENCE OESIGNATOR! S ) : BA05 B702 



10 BANK TRANSACTION OATE 

(SPEC: TYPE' N MIN' 6 : MAX' 6) 

OATE (YYWOO) THE BANK RECORDED THE TRANSFER OF 
FUNDS 

REFERENCE OESIGNATOR! S ) : B703 



11 BILLING COOE 

(SPEC: TYPE' A MIN' I; MAX' 1 ) 

TYPE OF 8ILLING REQUIREMENT FOR MULTIPLE EQUIPMENT 
SHIPMENT: 

COOE DEFINITION 

A TEMPORARILY ARTICULATED 10 AO 
H MULTIPLE SHIPMENT BILLING 

o multi-car transit 

R RULE 2A LEAO AND TRAILER EQUIPMENT ON 
SINGLE REYENUE BILL 
S SINGLE SHIPMENT 8ILLING 

T TRANSIT 8ILLING 

U UNIT TRAIN BILLING 

REFERENCE DESIGNATOR! S ) : B211 



12 BILLING DATE 

(SPEC: TYPE ' N MIN' 6: MAX' 6) 

DATE ( YYHMDO) OF THE CARRIER’S INVOICE 

REFERENCE DESIGNATOR! S ) : B304 COOL R503 



13 BOOKING NUMBER 

(SPEC: TYPE' AN MIN' 1 ; W4X- 10) 

NUMBER ASSIGNED BY THE CARRIER FOR SPACE 
RESERVATION 

REFERENCE OESIGNATOR! S) : Y301 Y401 Y501 



14 CARRIAGE VALUE 

(SPEC: TYPE' N MIN' 2: MAX' 3) 

CARRIAGE VALUE EXPRESSED IN WHOLE UNITS OF THE 
STANOARO MONETARY DENOMINATION FOR THE CURRENCY 
SPECIFIEO (IMPLIED OECIHAL POINT IS TO THE RIGHT 
OF THE EXPRESSED VALUE.) 

REFERENCE DESIGNATOR! S ) : M102 



15 CARR CERTIFICATED REL. DATE 

(SPEC: TYPE' N MIN' 6; MAX' 6) 

OATE (YYWHOO) OF CARRIER’S CERTIFICATE OF RELEASE 
AS REQUIRED BY CUSTOMS 

REFERENCE DESIGNATOR! S ) : X303 



16 CHARGE METHOD OF PAYMENT 

(SPEC: TYPE' A MIN' 1; MAX' 1) 

COOE DEFINING METHOD OF PAYMENT: 

COOE OEFINITION 

A PREPAID CASH 
8 PREPAIO CREDIT 
C COLLECT CASH 
0 COLLECT CREDIT 
E COLLECT 

REFERENCE OESIGNATOR! S ) : Llll LBll 



19 CITY NAME 

(SPEC: TYPE' AN MIN' 2: MAX' 79) 



FREE— FORM TEXT FOR CITY 


NAME 








REFERENCE OESIGNATOR! S) : 


0401 


0701 


E401 


E701 




F401 


F701 


F904 


H502 




L715 


N401 


NAM05 


RIN04 




S402 


S9Q3 


T209 


T210 




T404 


T 607 


2T03 


U401 




U901 


V405 


Y 104 





20 CLIENT BANK NUMBER 

(SPEC: TYPE' N MIN' 3: MAX' 9) 

FEDERAL RESERVE ROUTINC COOE (SEE APPENOIX A-A4) 

REFERENCE DESIGNATOR! S) : C204 



21 C.0.0. CURRENCY 

(SPEC: TYPE' A MIN' 2: MAX' 2) 

STANDARD ISO COOE FOR THE COUNTRY IN WICH THE 
C.0.0. CURRENCY IS SPECIFIED (SEE APPENOIX A-A5) 

REFERENCE OESIGNATOR! S ) : 005 C701 



22 COMMODITY CODE 

(SPEC: TYPE ' AN MIN' 2: MAX' 10) 

ALPWA/NUMERIC COOE USED TO OESCRIBE A COMMOOITY OR 
GROUP OF COMMOOITIES FOR RATING AND BILLING PURPOSES 
ALSO SEE: COMMOOITY COOE QUALIFIER (23) 

REFERENCE OESIGNATOR! S ) : Et07 1503 1R03 1R04 

1R05 1R04 1R07 TD104 

5T01 HOI 11 M2 03 



23 COMMODITY COOE QUALIFIER 

(SPEC: TYPE' A MIN' f; MAX' 1) 

QUALIFIER FOR THE COMMOOITY COOING SYSTEM USED TO 
OEFINE THE ITEM LADING DESCRIPTION (SEE APPENDIX A- 
Afc THRU A 13. A33) 

CODE OEFINITION 

A SCHEDULE A. TARIFF SCHEDULES OF THE 
UNITEO STATES ANNOTATEO 

3 U.S. FOREIGN TRAOE SCHEOULE B. STATISTICAL 
CLASSIFICATION OF OOHESTIC ANO FOREIGN 
COMMOOITIES EXPORTED FROM THE UNITED 
STATES 

C CAMAOIAN FREIGHT CLASSIFICATION 
E COOROINATEO MOTOR FREIGHT CLASSIFICATION 
H BRUSSELS NOMENCLATURE HARMONIZED SYSTEH 
HARMONIZED 8TN I 
M MUTUALLY OEFINEO 

N NATIONAL MOTOR FREIGHT CLASSIFI CATION 

! NMFC ) 

S STANOARO INTERNATIONAL TRAOE CLASSI- 



Figure 4.10 Data Dictionary. 
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associated kith the data segment and the third column indi- 
cates whether the data element is mandatory (II) , optional 
(0) , or conditional (C) . Additional information is 

contained in the remaining columns. These tables are used 
in conjunction with the data dictionary which describes 
individual data elements, to form the logical schema. 

To define processing, transactions should be 
defined. Transactions represent events in the real world 
and in EDI transaction sets represent paperwork which docu- 
ment a real world event. Transaction sets are defined in 
terms of the data segments from which they are built. in a 
sense this is an extension of the logical schema. Figures 
4.13 and figure 4.14 are a sample of two EDI tables which 
list transaction sets and the data segments they include 



[Ref. 


19]. In Table 1 (figure 


4. 


13) the 


tran 


sactic 


n set 


titled 


"flight confirmation" 


is 


assigned 


set 


ID n 


umber 


"101". 


This transaction set 


is 


composed 


of 


eight 


data 



segments. These data segments can be identified using Table 
2 (figure 4.14) by finding the set title ’’flight confirma- 
tion" and the set ID number "101". The second column under 
"flight confirmation" lists each data segment associated 
with the transaction set and the third column indicates 
whether its use is mandatory, optional, or conditional. 
Additional information is provided in the remaining columns. 

The purpose of a design review is to identify 
flaws. Documentation from the previous stages is examined 
and problems are identified and recommendations for resolu- 
tion are made. 

2 • Phy sic al Data B ase Design 

Since -EDI is not a data case management system as 
such, the steps of physical data base design apply only in a 
loose sense. The physical design differs from the logical 
design primarily in the sense that the physical schema 
provides for the implementation of the logical schema. 
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TABLE 3 - •SEGMENT NAMES 



TABLE 3 - SEGMENT NAMES 





Segment 


Data 


Segment Name 


ID 


Elements 
(Table 4) 


CONTROL HEADER (FUNCTIONAL GROUP) 


XX 


5 


CONTROL TRAILER (FUNCTIONAL GROUP) 


GE 


3 


ENDING SEGMENT (TRANSACTION SET) 


SE 


2 


STARTING SEGMENT (UCS TRANSACTION SET) 


STR 


2 


REJECTION 


A 1 


4 


BEGINNING SEGMENT FDR MANIFEST 


BO 


5 


BEGINNING SEGMENT FOR BOOKING DR P ICK-UP/DELI VERY 


B 1 


3 


BEGINNING SEGMENT FDR SHIPMENT INFORMATION TRANSACTION 


B2 


17 


BEGINNING SEGMENT FDR CARRIERS INVOICE 


B3 


1 1 


BEGINNING SEGMENT FDR INQUIRY OR REPLY 


B4 


8 


BEGINNING SEGMENT FDR ACCEPTANCE/REJECTION 


B5 


4 


BEGINNING SEGMENT FDR PAYERS AUTHORIZATION 


B6 


7 


BEGINNING SEGMENT FOR COMPLETED PAYMENTS 


37 


3 


BEGINNING SEGMENT 


B8 


5 


BEGINNING SEGMENT FOR REPETITIVE PATTERN MAINTENANCE 


B9 


8 


BEGINNING SEGMENT FDR ADVANCE CONSIST 


BA 


5 


BEGINNING SEGMENT FDR FILE TRANSFER INFORMATION 


BGF 


3 


BEGINNING SEGMENT 


BSG 


2 


FREIGHT PAYMENT 


CO 


4 


COMPLETED PAYMENTS 


Cl 


6 


BANK ID 


C2 


7 


CURRENCY 


C3 


6 


COMMERCIAL INVOICE TOTAL PRICING 


C7 


3 


COMMERCIAL INVOICE CERTIFICATIONS AND CLAUSES 


C8 


3 


CONSIGNEE NAME 


01 


4 


CONSIGNEE ADDRESS 


02 


2 


CONSIGNEE CITY 


04 


5 


CONSIGNEES THIRD PARTY 


05 


4 


CONSIGNEES THIRD PARTY ADDRESS 


06 


2 


CONSIGNEES THIRD PARTY CITY 


07 


4 


DELIVERY ROAD CODE 


08 


1 


DESTINATION STATION 


09 


4 


document references 


DR 1 


6 


EMPTY CAR DISPOSITION - PENDED DESTINATION CONSIGNEE 


El 


3 


EMPTY CAR DISPOSITION - PENDED DESTINATION CITY 


E4 


4 


EMPTY CAR DISPOSITION - PENDED DESTINATION ROUTE 


£5 


4 


EMPTY CAR ADVANCE DISPOSITION 


E6 


8 


CAR HANDLING INFORMATION 


E7 


6 


BLOCKING AND RESPONSE INFORMATION 


EB 


2 


EXCHANGE RATE/OROER ACCEPTANCE DATE 


ERO 


3 


CONSIGNOR NAME 


FI 


4 


CONSIGNOR ADDRESS 


F2 


2 


CONSIGNOR CITY 


F4 


5 


CONSIGNORS THIRD PARTY 


F5 


4 


CONSIGNORS THIRD PARTY ADDRESS 


F6 


2 


CONSIGNORS THIRD PARTY CITY 


F7 


4 


ORIGIN STATION 


F9 


7 


SHIPMENT TYPE INFORMATION 


G1 


3 


BEYOND ROUTING 


G2 


2 


brokerage INFORMATION 


G3 


3 


GOODS DETAILS 


GDI 


10 


HAZARDOUS MATERIAL 


HI 


5 


ADDITIONAL HAZARDOUS MATERIAL DESCRIPTION 


H2 


2 


special handling instructions 


H3 


4 


CAR SERVICE ORDER 


H5 


3 


INVOICE TERMS AND CONDITIONS 


ITC 


9 


INVOICE ITEM LINE 


ITL 


6 


REMARKS 


K 1 


2 


ADMINISTRATIVE MESSAGE 


K2 


1 


FILE INFORMATION 


K3 


1 


LINE ITEM - QUANTITY AND WEIGHT 


LO 


10 


RATE AND CHARGES 


LI 


13 


T AR£ WEIGHT 


L2 


2 


TOTAL WEIGHT AND CHARGES 


L3 


10 


MEASUREMENT 


L4 


4 


DESCRIPTION. MARKS AND NUMBERS 


L5 


8 


CARRIERS LINE ITEM REFERENCE NUMBER 


L6 


2 


TARIFF REFERENCE 


L7 


16 


LINE ITEM SUBTOTAL 


L8 


1 1 


CHARGE DETAIL 


L9 


2 


LETTER OF CREDIT REFERENCE 


MO 


3 


■ INSURANCE 


Ml 


6 


SALES/DELIVERY TERMS 


M2 


6 


RELEASE 


M3 


1 


CONSOLIDATION MANIFEST INFORMATION 


M4 


5 


MANIFEST LINE IDENTIFICATION DATA 


MS 


8 


REPETITIVE PATTERN NUMBER 


M6 


4 


SEAL NUMBERS 


M7 


4 



Figure 4.11 
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TABLE 4 - SATA ELEMENTS IN EACH SEGMENT 



Segment 


Data 


Require- 


Special 


Loca t 1 on 


In 


Element 


ment 


Process 


Master Record 


XX 


142 


M 


0 


--> 


<-- 


XX 


124 


M 


0 


— > 


<-- 


XX 


29 


M 


0 


--> 


<-- 


XX 


30 


M 


0 


--> 


<-- 


XX 


2B 


M 


0 


--> 


<-- 


GE 


97 


M 


0 


— > 


<-- 


GE 


96 


C 


0 


--> 


< — 


GE 


23 


c 


0 


--> 


< -- 


SE 


96 


M 


A16 


--> 


<-- 


SE 


329 


C 


A 1 7 


--> 


< -- 


STR 


143 


M 


0 


--> 


<-- 


STR 


329 


M 


0 


--> 


<-- 


A 1 


131 


M 


O 


--> 


<-- 


A 1 


126 


M 


0 


--> 


<~ 


A 1 


44 


M 


0 


-- > 


<-- 


A 1 


43 


M 


0 


— > 


<-- 


BO 


143 


M 


0 


— > 


< — 


BO 


215 


M 


0 


— > 


<-- 


BO 


214 


M 


0 


-- > 


<-- 


BO 


22B 


C 


0 


--> 


<-- 


BO 


91 


c 


0 


--> 


< -- 


B 1 


143 


M 


0 


’ --> 


<-- 


B 1 


145 


M 


0 


-- > 


<-- 


B 1 


239 


C 


0 


— > 


< -- 


B2 


143 


M 


0 


— > 


<-- 


B2 


298 


M 


0 


--> 


< - - 


B2 


154 


0 


0 


--> 


<-- 


B2 


223 


0 


E0405 


-- > 


<-- 


B2 


129 


0 


E0405 


--> 


< -- 


B2 


145 


0 


0 


--> 


< — 


B2 


IBB 


c 


O 


--> 


< -- 


B2 


146 


M 


0 


--> 


< .. 


B2 


160 


0 


0 


--> 


<-- 


B2 


147 


c 


0 


--> 


<-- 


B2 


1 1 


0 


0 


--> 


<-- 


B2 


226 


0 


0 


--> 


<«. 


B2 


195 


0 


0 


-- > 


<-- 


B2 


199 


0 


0 


-- > 


<-- 


B2 


57 


0 


0 


— > 


< — 


B2 


B6 


c 


O 


--> 


<-- 


B2 


460 


0 


0 


--> 


<-- 


B 3 


143 


M 


o 


--> 


<-- 


B3 


76 


M 


0 


-- > 


< — 


B3 


145 


c 


o 


--> 


< — - 


B3 


146 


M 


0 


--> 


< — 


B3 


IBB 


c 


o 


-- > 


<-- 


B3 


12 


M 


0 


— > 


<-- 


B3 


193 


0 


0 


— > 


<-- 


B3 


202 


0 


0 


— > 


<-- 


B3 


32 


0 


P0910 


--> 


<-- 


B3 


33 


c 


P0910 


--> 


<-- 


B3 


140 


c 


0 


--> 


<-- 


B4 


143 


M 


0 


-- > 


<-- 


B4 


71 


c 


0 


— > 


<-- 


B4 


157 


c 


C0N3 


--> 


<-- 


B4 


15B 


c 


0 


--> 


<-- 


B4 


161 


c 


o 


--> 


<-- 


B4 


159 


c 


0 


--> 


<-- 


B4 


206 


c 


C0N7 


-- > 


<-- 


B4 


207 


c 


P070B 


— > 


<-- 


B5 


143 


M 


O 


--> 


<-- 


B5 


2 


M 


0 


--> 


<-- 


B5 


123 


M 


O 


-- > 


<-- 


B5 


2B 


M 


0 


— > 


<- - 


B6 


143 


M 


0 


— > 


<-- 


B6 


145 


M 


O 


--> 


<-- 


B6 


75 


M 


0 


--> 


< -- 


B6 


76 


c 


O 


— > 


< — 


B6 


9 


c 


0 


--> 


<-- 


B6 


245 


0 


O 


--> 


< — — 


B6 


249 


c 


0 


--> 


< 


B7 


143 


M 


0 


--> 


<-- 


B7 


9 


M 


0 


- - > 


<-- 


37 


10 


M 


0 


--> 


< -- 


BB 


143 


M 


o 


--> 


<— 


3B 


12B 


M 


0 


--> 


<-- 


BB 


127 


M 


0 


--> 


< — 


BB 


125 


M 


0 


--> 


< — 


BB 


1 8B 


C 


0 


--> 


< -- 



J 



1,12 Data Elements in Each Data Segment. 
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TABLE 1 - SET NAMES 



I 



Set Name 



Set ID Segment I 
(Taole 2) 



FLIGHT CONFIRMATION 
SHIPMENT INFORMATION (AIR) 

CONTAINER/EOUIPMENT TRANSFER (AIR) 

SHIPMENT INFORMATION FOR EXPORT DECLARATION (AIR) 

SHIPMENT INFORMATION FOR IMPORT (AIR) 

SHIPMENT INFORMATION FOR PICK-UP/OELIVERY OROER (AIR) 
FREIGHT OETAILS ANO INVOICE (AIR) 

FREIGHT OETAILS AND INVOICE SUMMARY (AIR) 

INQUIRY (AIR) 

SHIPMENT IDENTITIES ANO STATUS REPLY (AIR) 

STATUS OETAILS REPLY (AIR) 

REPETITIVE PATTERN MAINTENANCE (AIR) 

SHIPMENT INFORMATION (MOTOR) 

CONTAINER/EQUIPMENT TRANSFER (MOTOR) 

SHIPMENT PICK-UP OROER (MOTOR) 

SHIPMENT INFORMATION FOR EXPORT DECLARATION (MOTOR) 
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Figure 4.14 Data Segments in Each Transaction Set. 
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V. SUMMARY 



Cue cf the major problems in RWMCCS ADP today is the 
inability to meet the requirement for timely exchange of 
data among widely separated commands in a tine sensitive 
environment while preserving security and accuracy. The 
current method is to have commands use their unique applica- 
tions for individual processing requirements and then use 
one of a few standard applications in order to interface 
with ether commands in a form which can be interpreted by 
them. This method entails many problems, not the least of 
which is a requirement for manual intervention to translate 
data among various applications. Manual intervention 
increases the likelihood of problems with timeliness, accu- 
racy, and security. 

By implementing the EDI concept the members of the 
WWMCCS community could substantially reduce these problems 
by reducing the requirement for special interfaces (manual 
or automated) between each set of applications which need to 
exchange data. By tsing the EDI concept, any command which 
could translate to and from the EDI standard data set could 
exchange data with any other participating command. 

Figure 5. 1 shows how data sets are exchanged among 
commands today. each dotted line represents an interface 
program designed to "translate" data between an application 
at one command and an application at another. Today if MSC 
is to furnish information directly to three applications at 
other commands (e.g. MTMC, JDA, MAC) special interface soft- 
ware must be written or all commands must be restricted to 
using the same software and hardware. In addition, if any 
other commands needed to exchange data, they would need 
additional software to facilitate those interfaces (eg. MTMC 
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and JEA) . Figure 5.2 
using the EEI concept, 
will serve to further 
standard data set. 



Indicates how data would be exchanged 
A sample data exchange using data 
illustrate the function of the EDI 




MAC MSC MTMC 



JEA 

1 9 



Figure 5. 1 WWMCCS Interfaces Today. 



MSC (2250061285) 



MAC (£50612) . . . EDI (120635) . . . MTMC (120685) 



Figure 5.2 Data Exchange Using EDI. 



MSC is required to transmit information which contains 
in it a data element which represents a date. They 
transmit this information to JDA, MTMC, and MAC. Due to 
their unique applications, MSC represents this date as 
hour-minures-mont h-day-ye ar (eg. 2250061285). 

The MSC-EDI interface translates this to the EDI stan- 
dard for date which is expressed (by community 
agreement) as day-mcnth-y ear (eg. 120685). 

The EDI software packages the information for transmis- 
sion and sends it to the appropriate commands. 
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When the data is received at JDA, they translate, using 
command software, into the format required by unicue 
applications at JDA (eg. year-month- day 85061 2) . When 
the data is received at M1MC it is used in the EDI 
format. 

The most obvious advantage is that if MTHC also interfaces 
with JDA nc additional interfaces would be required using 
the EDI concept. 

The EDI system provides for the transmission of the data 
in a standard format. Each command provides the means of 
translating their data to to and from the standard with 
command unique software. This does, however, reduce the 
number cf required interfaces and permits reduction of 
duplication in establishing a distributed data base 
approach. Each command will only require one interface, 
regardless of the total number of commands participating. 
Under the current system, if each command is to exchange 
data with every ether participating command the total number 
of interfaces required for each command would be N- 1 (where 
N represents the number of commands participating) . The EDI 
standard tables could contain codes indicating which command 
is responsible for certain kinds of transaction sets or data 
segments and to whom these are distributed. In addition, 
when information is requested through the EDI interface, the 
central directory would have the means to locate the appro- 
priate command from which to draw the information. This 
would reduce the require ment for each command to maintain 
individual data directories for all the commands with which 
they interface. The use of a common interface permits many 
widely separated data bases to function virtually as a 
distributed data base. This will help meet the identified 
requirement for a distributed data base approach to support 
JOPES. It is not a distributed data base in the routine 
sense but rather an interface which permits the exchange of 
data among separate cata bases. 
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TRANSACTION SET EXAMPLE - INVOICE # 44887221 



(BG SEGMENT) 
(GS SEGMENT) 



S7*880* 

G0 1*82 101 6*4488722 1*820928*9034 1 7 
LS*0 1 00 

N 1 *BT**9*98765432 1 0002 

N1*S7*SALES C0MPANY*9*98765432 10070 

N2*GR0CERY WAREHOUSE * 70 

N3*22 WEST LONG ST 

N4*R!CHLAND*CA*94800 

N 1*BY**9*98765432 1000 1 

N1*SU*ABC COMPANY. INC *9* 1 23456789000 1 

IE*0 1 00 

LS*0200 

G 1 7* 1 1*C4*13 1 700*0037 1 3912345 
G69*ABC TRPCL FRUIT SALAD 
G20*24* 1 600*OZ 
LS*02 1 0 

G72* 1 *02**- 1 3 1700**** 1 000*C A 
LE*02 1 0 

G 1 7*30*CA*97600*0037 1 3967890 
G69*ABC CUT GREEN BEANS 
G20*24*800*OZ 
LE*0200 

G23*0 1*3*2000** 1 0**30 
G25*PB*03 
G31*41*CA 
G33*42450*4 160 1 
SE*27* 

<GE SEGMENT) 

(EG SEGMENT) 
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Figure 5-4 Transaissicn in EDI Format, 
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